“I need solitude for my writing; not 'like a hermit' - that wouldn't be enough - but like a dead man.”
― Franz Kafka

MirrorMaker 也就是所謂的跨叢集資料鏡射，通常有幾種使用場景，像是災害備援系統，將整個叢集複製放置於另外一個地方，如果遇到意外事件導致叢集失敗，可以立刻將資料來源切換到備援系統，而這種跨叢集資料會遇到幾個問題，延遲性的問題，叢集間的傳輸速率會因為網路間的距離跟網路傳導次數而增加、成本的問題，因為無論是企業自建機房或是在雲端上建構，頻寬的成本都是十分驚人的，必須考慮到是否有必要性

除了 MirrorMaker 之外，也有 Uber 的 uReplicator，和 Confluent 的 Replicator，Uber當年在使用 MirroMaker 遇到了不少問題，隨著他們業務增長、主題跟分區也逐漸增加，在消費者重新平衡的花費時間增加到過長，導致跟同步的資料堆積，需要花費很多時間去消耗，會導致目標叢集的消費者的消費延遲，另外就是新增主題有相當的困難性，因為新增主題會導致消費者的再平衡，從而導致剛剛的問題又再度發生，Uber 的 uReplicator 就是藉由 Apache 的 Helix 元件來解決這個問題

Confluent 的 Replicator 主要是用來解決叢集設定的問題，常常會發生修改本地叢集，卻漏改目標叢集、區域叢集，還有就是管理多個叢集，通常管理一對一的叢集設定檔就是相當困難的，因此 Replicator 可以透過 Kafka Connect 去幫忙管理設定檔